Event-driven, asset-centric key management in a smart grid

ABSTRACT

A security management system comprises a key management sub-system, an asset/workload management sub-system, and an event management sub-system. The event management sub-system detects events. The asset/workload management sub-system correlates events (irrespective of type) with the assets that generate them, and the key management sub-system uses the event-asset associations determined by the asset/workload management sub-system to automatically orchestrate the necessary key management activities (e.g., key creation, revocation, refresh, etc.) across the impacted components in the information technology and operational realms to ensure data security. In one use case, a security event detected by the event management sub-system triggers one or more actions within the asset/workload management sub-system. Service configuration records are identified from this scan, and assets defined in those records are identified. An event-asset association is then supplied to the key management sub-system, which uses this information to determine a key management operation.

BACKGROUND OF THE INVENTION

Technical Field

This disclosure relates generally to securing information in anindustrial or other environment (e.g., in a next generation power grid)and, in particular, to improved techniques for key management to protectend-to-end data security in such an environment.

Background of the Related Art

The recent evolution of the smart grid brings about a convergence ofelectrical power-engineering improvements, networks, and communicationsand computing technology to transform the one-way power flow value-chaininto a fabric of two-way power and information sharing infrastructure.To this end, modern electrical power devices (typically used intransmission and distribution domains) of the power grid today have acollection of sensing, computing, communication and control elements.For example, advanced metering infrastructures are now being put intoplace to remotely read electrical meters, to manage and control electricsubstation devices, and to control power switching. The data collectedfrom these field devices often is used for different purposes, such asbilling, distribution control, and energy management. The collected dataoften is aggregated and then analyzed by business analytics andoptimization sub-systems to bring new models of pricing operationalefficiency and consumer service offerings. In addition,energy-optimization practices, such as electrical demand-responseinitiatives, need to send commands down to these devices formaintenance, calibration and control. Consequently, these businesssystems, as well as the field devices, often depend heavily on theintegrity of the data collected and the integrity of the controlcommands sent. In addition, confidentiality of data elements is neededto preserve the behavioral and personally identifiable information (PII)of the customer. Further, many of these field equipment and systems areclassified as critical cyber assets, with associated governmentregulations (e.g., NERC-CIP and FERC) being applicable thereto, makingdata security even more vital. This data security can be achieved byproper design and deployment of a cryptographic infrastructure tocoexist along with the data flow components.

Key management is the management of cryptographic keys for acryptosystem. Key management typically involves the generation,exchange, storage, use, and replacement of keys. Key management oftenbecomes the most challenging aspect of deploying a cryptoinfrastructure.

The National Institute of Science and Technology (NIST) has publishedguidelines (NIST Interagency Report 7628: Guidelines for Smart GridCyber Security) to act as a framework and roadmap describing securitystandards that are applicable (or are likely to be applicable) to thesmart grid. This report suggests that a key management scheme be used toprotect cryptographic materials, as well as to provide sufficient keydiversity. Further, the report suggests that symmetric cipher systems(and thus symmetric keys) be used provided that adequate coordinationamong the key producer and the key consumers can be enforced.

Despite the importance of data security in this model, there are seriouschallenges and inhibitions that have prevented end-to-end data securityfrom being implemented effectively in the smart grid. There are numerousreasons why this is the case. Many devices lack the processing power andsufficient random-number generation resources to handle cryptographickey generation. Also, many devices have yet to be enhanced withcommunication elements that can respond to remote commands, or tocollect data and transfer it remotely. While there are new vendors thathave begun to provide auxiliary components that can perform suchfunctions and provide basic key storage, these additional components arenot supplemented with robust key management schemes and typically do nothave connectivity to crypto-key servers, certificate authorities, orother resources (e.g., OCSP servers). Where devices do include nativesecurity features, typically the authentication operations are based onasymmetric keys embedded in the devices. While asymmetric cipher systemsprovide good security, they are computationally-intensive. Moreover,unlike conventional Internet-based secure transactions, the connectivitybetween smart grid devices and business applications may belong-standing and sometimes persistent, and this necessitates morerobust and strategic key management schemes to protect data. Further,third party service providers also may create additional privacyconcerns because they provide value-added services (e.g., consumerenergy management) that generate detailed information about behavioralpatterns and profiles. Another problem is that current practices oftenexpect business application-layer software assets to build data securityand key management solutions between just a pair of communicatingentities (namely, the endpoint devices and themselves). Data, however,often is shared between and among multiple business systems; thus, caremust be taken while provisioning all the keys involved. This requirementbecomes especially cost-prohibitive as this overhead is multipliedseveral times for each security association. Thus, the scalability ofkey management schemes for data in motion, and data at rest withinsystems, becomes very difficult and intractable to manage.

Indeed, key management schemes, when implemented, are provisioned in avacuum, typically within individual vendor-supplied subsystems, withlittle or no integration across other operational systems. A more robustand integrated solution is necessary.

The subject matter of this disclosure addresses these and otherdeficiencies of the prior art.

BRIEF SUMMARY

According to this disclosure, cipher key management is provided for aninfrastructure (e.g., a smart grid) that is characterized bybi-directional connection of electricity and information flows.

In the approach herein, a security management system comprises a keymanagement sub-system, an asset/workload management sub-system, and anevent management sub-system. The event management sub-system detects,among many other events, security events, which are events that arisefrom security policy enforcement violations. The event management systemalso responds to other types of events, such as registration events thatarise during service establishment, maintenance-related events, andothers. The asset/workload management sub-system operates to correlatethe event (regardless of type) with the assets that generate them, andthe key management sub-system uses the event-asset associationsdetermined by the asset/workload management sub-system to automaticallyorchestrate the necessary key management activities (e.g., key creation,revocation, refresh, or the like) across the impacted components in theinformation technology (IT) and operational realms to ensure end-to-enddata security.

In a representative use case involving a security compromise, a securityevent detected by the event management sub-system triggers one or moreactions within the asset/workload management sub-system. One or moreservice configuration records are identified from this scan, and one ormore assets (that may have generated the security event) defined inthose records are identified (e.g., from an asset database). Based onthis information, one or more event-asset associations are identified.As necessary, multiple event-asset associations may be cross-referenced,which facilitates key establishment across multiple and diverse businesssystems. The key management sub-system uses the event-asset informationto automatically configure a key management operation (e.g., generation,submission, retrieval and deletion of cryptographic keys). Themanagement operation is then executed.

In addition to managing keys in response to security events, thetechniques may be used to implement key management across multiple othertypes of use cases in the operating environment.

The foregoing has outlined some of the more pertinent features of theinvention. These features should be construed to be merely illustrative.Many other beneficial results can be attained by applying the disclosedinvention in a different manner or by modifying the invention as will bedescribed.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and theadvantages thereof, reference is now made to the following descriptionstaken in conjunction with the accompanying drawings, in which:

FIG. 1 depicts an exemplary block diagram of a distributed dataprocessing environment in which exemplary aspects of the illustrativeembodiments may be implemented;

FIG. 2 is an exemplary block diagram of a data processing system inwhich exemplary aspects of the illustrative embodiments may beimplemented;

FIG. 3 illustrates an exemplary Advanced Metering Infrastructure (AMI)architecture in which the disclosed subject matter may be implemented;

FIG. 4 illustrates an exemplary set of security associations in the AMIarchitecture;

FIG. 5 is a block diagram of a security management system according tothis disclosure;

FIG. 6 illustrates a process flow of how the component sub-systems ofthe security management system interact with one another in one use caseof the disclosed subject matter involving a security event;

FIG. 7 illustrates the AMI architecture of FIG. 3 after it has beenmodified to include the security management system of this disclosure;

FIG. 8 illustrates how keys may be structured and organized by a keymanagement sub-system of the security management system;

FIG. 9 illustrates how security management system may be used to provideautomated key revocation/refresh upon a security compromise; and

FIG. 10 is a process flow illustrating an algorithm for key revocationand refresh.

DETAILED DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT

With reference now to the drawings and in particular with reference toFIGS. 1-2, exemplary diagrams of data processing environments areprovided in which illustrative embodiments of the disclosure may beimplemented. It should be appreciated that FIGS. 1-2 are only exemplaryand are not intended to assert or imply any limitation with regard tothe environments in which aspects or embodiments of the disclosedsubject matter may be implemented. Many modifications to the depictedenvironments may be made without departing from the spirit and scope ofthe subject matter.

Enabling Technologies

With reference now to the drawings, FIG. 1 depicts a pictorialrepresentation of an exemplary distributed data processing system inwhich aspects of the illustrative embodiments may be implemented.Distributed data processing system 100 may include a network ofcomputers in which aspects of the illustrative embodiments may beimplemented. The distributed data processing system 100 contains atleast one network 102, which is the medium used to provide communicationlinks between various devices and computers connected together withindistributed data processing system 100. The network 102 may includeconnections, such as wire, wireless communication links, or fiber opticcables.

In the depicted example, server 104 and server 106 are connected tonetwork 102 along with storage unit 108. In addition, clients 110, 112,and 114 are also connected to network 102. These clients 110, 112, and114 may be, for example, personal computers, network computers, or thelike. In the depicted example, server 104 provides data, such as bootfiles, operating system images, and applications to the clients 110,112, and 114. Clients 110, 112, and 114 are clients to server 104 in thedepicted example. Distributed data processing system 100 may includeadditional servers, clients, and other devices not shown.

In the depicted example, distributed data processing system 100 is theInternet with network 102 representing a worldwide collection ofnetworks and gateways that use the Transmission ControlProtocol/Internet Protocol (TCP/IP) suite of protocols to communicatewith one another. At the heart of the Internet is a backbone ofhigh-speed data communication lines between major nodes or hostcomputers, consisting of thousands of commercial, governmental,educational and other computer systems that route data and messages. Ofcourse, the distributed data processing system 100 may also beimplemented to include a number of different types of networks, such asfor example, an intranet, a local area network (LAN), a wide areanetwork (WAN), or the like. As stated above, FIG. 1 is intended as anexample, not as an architectural limitation for different embodiments ofthe disclosed subject matter, and therefore, the particular elementsshown in FIG. 1 should not be considered limiting with regard to theenvironments in which the illustrative embodiments of the presentinvention may be implemented.

With reference now to FIG. 2, a block diagram of an exemplary dataprocessing system is shown in which aspects of the illustrativeembodiments may be implemented. Data processing system 200 is an exampleof a computer, such as client 110 in FIG. 1, in which computer usablecode or instructions implementing the processes for illustrativeembodiments of the disclosure may be located.

With reference now to FIG. 2, a block diagram of a data processingsystem is shown in which illustrative embodiments may be implemented.Data processing system 200 is an example of a computer, such as server104 or client 110 in FIG. 1, in which computer-usable program code orinstructions implementing the processes may be located for theillustrative embodiments. In this illustrative example, data processingsystem 200 includes communications fabric 202, which providescommunications between processor unit 204, memory 206, persistentstorage 208, communications unit 210, input/output (I/O) unit 212, anddisplay 214.

Processor unit 204 serves to execute instructions for software that maybe loaded into memory 206. Processor unit 204 may be a set of one ormore processors or may be a multi-processor core, depending on theparticular implementation. Further, processor unit 204 may beimplemented using one or more heterogeneous processor systems in which amain processor is present with secondary processors on a single chip. Asanother illustrative example, processor unit 204 may be a symmetricmulti-processor (SMP) system containing multiple processors of the sametype.

Memory 206 and persistent storage 208 are examples of storage devices. Astorage device is any piece of hardware that is capable of storinginformation either on a temporary basis and/or a permanent basis. Memory206, in these examples, may be, for example, a random access memory orany other suitable volatile or non-volatile storage device. Persistentstorage 208 may take various forms depending on the particularimplementation. For example, persistent storage 208 may contain one ormore components or devices. For example, persistent storage 208 may be ahard drive, a flash memory, a rewritable optical disk, a rewritablemagnetic tape, or some combination of the above. The media used bypersistent storage 208 also may be removable. For example, a removablehard drive may be used for persistent storage 208.

Communications unit 210, in these examples, provides for communicationswith other data processing systems or devices. In these examples,communications unit 210 is a network interface card. Communications unit210 may provide communications through the use of either or bothphysical and wireless communications links.

Input/output unit 212 allows for input and output of data with otherdevices that may be connected to data processing system 200. Forexample, input/output unit 212 may provide a connection for user inputthrough a keyboard and mouse. Further, input/output unit 212 may sendoutput to a printer. Display 214 provides a mechanism to displayinformation to a user.

Instructions for the operating system and applications or programs arelocated on persistent storage 208. These instructions may be loaded intomemory 206 for execution by processor unit 204. The processes of thedifferent embodiments may be performed by processor unit 204 usingcomputer implemented instructions, which may be located in a memory,such as memory 206. These instructions are referred to as program code,computer-usable program code, or computer-readable program code that maybe read and executed by a processor in processor unit 204. The programcode in the different embodiments may be embodied on different physicalor tangible computer-readable media, such as memory 206 or persistentstorage 208.

Program code 216 is located in a functional form on computer-readablemedia 218 that is selectively removable and may be loaded onto ortransferred to data processing system 200 for execution by processorunit 204. Program code 216 and computer-readable media 218 form computerprogram product 220 in these examples. In one example, computer-readablemedia 218 may be in a tangible form, such as, for example, an optical ormagnetic disc that is inserted or placed into a drive or other devicethat is part of persistent storage 208 for transfer onto a storagedevice, such as a hard drive that is part of persistent storage 208. Ina tangible form, computer-readable media 218 also may take the form of apersistent storage, such as a hard drive, a thumb drive, or a flashmemory that is connected to data processing system 200. The tangibleform of computer-readable media 218 is also referred to ascomputer-recordable storage media. In some instances,computer-recordable media 218 may not be removable.

Alternatively, program code 216 may be transferred to data processingsystem 200 from computer-readable media 218 through a communicationslink to communications unit 210 and/or through a connection toinput/output unit 212. The communications link and/or the connection maybe physical or wireless in the illustrative examples. Thecomputer-readable media also may take the form of non-tangible media,such as communications links or wireless transmissions containing theprogram code. The different components illustrated for data processingsystem 200 are not meant to provide architectural limitations to themanner in which different embodiments may be implemented. The differentillustrative embodiments may be implemented in a data processing systemincluding components in addition to or in place of those illustrated fordata processing system 200. Other components shown in FIG. 2 can bevaried from the illustrative examples shown. As one example, a storagedevice in data processing system 200 is any hardware apparatus that maystore data. Memory 206, persistent storage 208, and computer-readablemedia 218 are examples of storage devices in a tangible form.

In another example, a bus system may be used to implement communicationsfabric 202 and may be comprised of one or more buses, such as a systembus or an input/output bus. Of course, the bus system may be implementedusing any suitable type of architecture that provides for a transfer ofdata between different components or devices attached to the bus system.Additionally, a communications unit may include one or more devices usedto transmit and receive data, such as a modem or a network adapter.Further, a memory may be, for example, memory 206 or a cache such asfound in an interface and memory controller hub that may be present incommunications fabric 202.

Computer program code for carrying out operations of the disclosedsubject matter may be written in any combination of one or moreprogramming languages, including an object-oriented programming languagesuch as Java™, Smalltalk, C++, C#, Objective-C, or the like, andconventional procedural programming languages. Program code may bewritten in interpreted languages, such as Python. The program code mayexecute entirely on the user's computer, partly on the user's computer,as a stand-alone software package, partly on the user's computer andpartly on a remote computer, or entirely on the remote computer orserver. In the latter scenario, the remote computer may be connected tothe user's computer through any type of network, including a local areanetwork (LAN) or a wide area network (WAN), or the connection may bemade to an external computer (for example, through the Internet using anInternet Service Provider). The techniques herein may also beimplemented in non-traditional IP networks.

The hardware in FIGS. 1-2 may vary depending on the implementation.Other internal hardware or peripheral devices, such as flash memory,equivalent non-volatile memory, or optical disk drives and the like, maybe used in addition to or in place of the hardware depicted in FIGS.1-2. Also, the processes of the illustrative embodiments may be appliedto a multiprocessor data processing system, other than the SMP systemmentioned previously, without departing from the spirit and scope of thedisclosed subject matter.

Certain of the techniques described herein may operate in conjunctionwithin the standard client-server paradigm such as illustrated in FIG. 1in which client machines communicate with an Internet-accessible serveror portal executing on a set of one or more machines. End users operateInternet-connectable devices (e.g., desktop computers, notebookcomputers, Internet-enabled mobile devices, or the like) that arecapable of accessing and interacting with the portal. A client mayinteract with a server autonomously. Typically, each client or servermachine is a data processing system such as illustrated in FIG. 2comprising hardware and software, and these entities communicate withone another over a network, such as the Internet, an intranet, anextranet, a private network, or any other communications medium or link.A data processing system typically includes one or more processors, anoperating system, one or more applications, and one or more utilities.The applications on the data processing system provide native supportfor Web services including, without limitation, support for HTTP, SOAP,XML, WSDL, and UDDI, among others. Information regarding SOAP, WSDL andUDDI is available from the World Wide Web Consortium (W3C), which isresponsible for developing and maintaining these standards; furtherinformation regarding HTTP and XML is available from InternetEngineering Task Force (IETF). Familiarity with these standards ispresumed.

By way of further background, mobile device technologies also arewell-known. A mobile device is a smartphone or tablet, anInternet-connected appliance or device, or the like. A device of thistype typically comprises a CPU, computer memory, such as RAM, and a datastore. The device software includes operating system, and genericsupport applications and utilities. A device may include a separategraphics processing unit (GPU). A touch-sensing device or interface,such as a touch screen, may be configured to receive input from a user'stouch and to send this information to processor. Other input/outputdevices include software-based keyboards, cameras, microphones, and thelike. More generally, a mobile device is any wireless client device,e.g., a smart phone, a tablet, an intelligent appliance, a pager, apersonal digital assistant (PDA, e.g., with GPRS NIC), a mobile computerwith a smartphone client, or the like. Typical wireless protocols are:WiFi, GSM/GPRS, CDMA or WiMax. These protocols implement the ISO/OSIPhysical and Data Link layers (Layers 1 & 2) upon which a traditionalnetworking stack is built, complete with IP, TCP, SSL/TLS and HTTP. Amobile device may be a 3G- (or next generation) compliant device thatincludes a subscriber identity module (SIM), which is a smart card thatcarries subscriber-specific information, mobile equipment (e.g., radioand associated signal processing devices), a man-machine interface(MMI), and one or more interfaces to external devices. The mobile devicemay be an intelligent appliance.

The mobile device typically also has support for wireless local areanetwork (WLAN) technologies, such as Wi-Fi, home area network (HAN)technologies, such as Zigbee, and the like.

Smart Grid

The smart grid is the next generation power grid. It is based onbi-directional (two-way) connection of electricity and informationflows. The smart grid combines the legacy electricity grid withcontemporary communications and computing technologies. The smart griddelivers electricity between generators and end users (e.g., industrial,commercial and residential). The approach uses bi-directionalinformation flow to control intelligent devices to reduce energyconsumption and to balance electricity supply and demand. As iswell-known, the Advanced Metering Infrastructure (AMI) is an importantaspect of the smart grid; an AMI deployment relies upon a smart meter,which is an end user device that collects data and communicates with aservice provider in the smart grid.

FIG. 3 illustrates a representative AMI deployment scenario. Typically,an AMI deployment comprises a smart meter, its associated head end, andintermediary devices and networks. In this example, the smart meter 300is located at an end use location. Typically, the smart meter 300communicates over a wireless network (e.g., an 802.11e-based network) toa pole-mounted cell relay 302 or other intermediary. The relay 302 iscoupled to an advanced meter head-end 304 located in a data center. Awide area network (WAN) fabric 306 interconnects the relay to thehead-end. Typically, a meter vendor provides all of the AMI technologyfrom the meter head-end 304 down to the meter 300. The AMI deployment iscoupled to an enterprise service bus 308 as the pathway for transactionswith one or more applications. The enterprise service bus (ESB) 308 ismodeled using the Common Information Model (CIM). This standard has beenofficially adopted by the International Electrotechnical Commission(IEC), as Standards IEC-61968 and IEC-61970. CIM facilitates informationexchange about the configuration and status of an electrical network tobe exchanged between application software. The standard is maintained asa UML model that defines a common vocabulary and basic ontology foraspects of the electric power industry. The CIM in particular can beused to derive design artifacts (e.g., XML Schema, RDF Schema) as neededfor the integration of related application software. The IEC CIM formathas been adopted by the major energy management software vendors toallow data exchange between their applications, independent of internalsoftware architecture or operating platform differences. A similarhierarchical model exists for distribution networks and that addressesdata extraction from electrical sub-stations. In the example deploymentshown in FIG. 3, the AMI deployment is coupled via the ESB 308 toapplications that use IEC 61968 CIM for enterprise integration.

As also seen in FIG. 3, and without limitation, typically theapplication software comprises customer information systems 310, billingsystems 312, work order management systems 314, configurationrecord/asset management systems 316, and outage management systems 318.One or more of these application software systems may be co-located orremote from one another, combined with one another, executed in acloud-based environment, or the like. Each of these systems may besupplied by different vendors. A firewall 320 may be used to protect theenterprise service bus 308 and the associated application software. Thefirewall may be supported within a Service Oriented Architecture (SOA)middleware appliance, such as IBM® DataPower®.

Generalizing, the entities (e.g., devices, service applications, and thelike) in the operating environment may also be considered “nodes” in adata and power delivery network. In the smart grid embodiment, the nodesare the meters, meter head-end, service applications, and the like,that, together, facilitate delivery of electricity (e.g., over a legacydelivery system) under the control of the two-way information flows asdescribed. Typically, a given pair of nodes (a “segment”) may have asecurity association associated therewith.

Referring now to FIG. 4, an exemplary set of security associations inthe AMI architecture is shown. These security associations are merelyrepresentative. In this example scenario, a first segment 400 (segmentA) represents a first security association defined between the head-endmeter at the data center and the smart meter that is located remotely(typically, at the end user location). A second segment 402 (segment B)represents a distinct security association between the head end meterand the application layers, which layers interact with the AMI using oneor more interfaces offered by the head end. Typically, the meter vendortakes ownership of providing a solution for the security requirements ofsegment A but not necessarily for segment B (the data traversing betweenthe applications and the meter head-end). In either segment, however,there is a need for key management to ensure that data security isenforced. The type of segmented (disjoint) key management approach shownin FIG. 4 is difficult to manage (especially where multiple differenttoolsets are used) and thus inhibits end-to-end data security fromscaling across multiple and diverse business systems.

As noted above, the subject disclosure that is now described addressesthese deficiencies.

Event-Driven, Asset-Centric Key Management

With the above as background, the following describes an inventivesecurity management system. As seen in FIG. 5, at a high level thesecurity management system 500 comprises three (3) primary functionalcomponents: a key management sub-system 502, an asset/workloadmanagement sub-system 504, and an event management sub-system 506. Theterms “system” and/or “sub-system” should be broadly construed, andthese terms may be used interchangeably with “modules,” “functions” and“components.” The functionalities described may exist in a standalonemanner, or they may be integrated in whole or in part. They may beco-located, or remote from one another, in whole or in part. They may beunitary, or they may comprise cooperating parts. They may be implementedin software, firmware, hardware and software, or the like. Typically, asystem or sub-system comprises computer system-executable instructions,such as program modules, being executed by a computer system. Generally,program modules may include routines, programs, objects, components,logic, data structures, and so on that perform particular tasks orimplement particular abstract data types. The functions may be practicedin distributed cloud computing environments where tasks are performed byremote processing devices that are linked through a communicationsnetwork.

In one embodiment, the key management sub-system is implemented as a keymanagement server that is secured within a secure, trusted enterprisenetwork zone. A representative key management server that may be usedfor this purpose is the IBM® Tivoli® Key Lifecycle Manager (TKLM). Thisserver typically executes in an application server/database serveroperating environment, such as on IBM WebSphere® Application Server, andDB2®.

In one embodiment, the asset management and workload managementsub-system is implemented by an enterprise asset manager server. Arepresentative server of this type is the IBM® Tivoli® Maximo EnterpriseAsset Manager For Utilities. This server also may execute in anapplication server/database server operating environment, such asdescribed above.

In one embodiment, the event management sub-system provides anintelligent infrastructure to notify subscribers, possibly withenriched, correlated events of interest and/or concern. A representativeserver of this type is the IBM® Tivoli® Netcool Omnibus product. Thisserver also may execute in an application server/database serveroperating environment, such as described above.

The above-identified commercial products are identified solely forexample purposes and not by way of limitation. Any product, service,program, process, or function may be substituted.

As will be described in more detail below, within the context of thisdisclosure, the event management sub-system 506 need not always play arole in every use case involving key management, although typically itcomes into play in situations when events involving potential keycompromises occur. For convenience, and not by way of limitation, anevent detected by the event management sub-system 506 is sometimesreferred to herein as a “security event” to distinguish it from, forexample, other types of events, such as registration events,maintenance-related events, and the like, that may also trigger actionswithin the asset/workload management sub-system 504. An example of thelatter type of event is establishment of a service relationship betweenor among various components that, in turn, requires the establishment ofkeys to enforce data security end-to-end. A particular example of thisservice relationship establishment (described below) is a meter oninitial deployment that registers through its head-end system, therebypublishing a “registration event” that triggers one or more actionswithin the asset/workload management sub-system. There may be many otheruse cases that are triggered by other types of events that have theeffect of triggering actions that involve key associations and theirmanagement. Thus, as used herein, the term “event” should be broadlyconstrued to refer to security-related events, registration-relatedevents, maintenance-related events, and others.

FIG. 6 illustrates one use case involving detection of a security eventby the event management sub-system. As described above, this is just oneuse case for the system, and it should not be taken by way oflimitation. In this example use case, the event management sub-system506 detects security events, the asset/workload management sub-system504 correlates the security events with the assets that generate them,and the key management sub-system 502 uses the event-asset associationsdetermined by the asset/workload management sub-system to automaticallyorchestrate the necessary key management activities (e.g., key creation,revocation, refresh, or the like) across the impacted components in theinformation technology (IT) and operational realms to ensure end-to-enddata security. In a representative method as illustrated by the processflow in FIG. 6, a security event is detected by the event managementsub-system. This is step 600. In one example, the security event arisesas an asynchronous event (e.g., a security incident). The security eventdetection triggers one or more actions within the asset/workloadmanagement sub-system. In particular, one or more service configurationrecords are identified from this scan, and one or more assets (that mayhave generated the security event) defined in those records are thenidentified (e.g., from an asset database). These operations generate oneor more event-asset association(s). This is step 602. At step 604, asnecessary multiple event-asset associations are cross-referenced(sometimes referred to as “linked”). As will be seen, suchcross-referencing provides a way for the security management system toperform key establishment across multiple and diverse business systems.Step 604 may not be required, depending on the nature and type of event.At step 606, the key management sub-system uses the event-assetinformation to configure one or more key management operations (e.g.,generation, submission, retrieval and deletion of cryptographic keys).At step 608, the key management operation is executed. Although notintended to be limited, preferably the operations carried out in FIG. 6occur automatically and autonomously in an AMI deployment that has beenconfigured to use the security management system.

FIG. 7 illustrates the enterprise/AMI deployment architecture of FIG. 3after it has been modified to include the security management system ofthis disclosure. In this embodiment, the key management sub-systemcomprising a cooperating set of components, namely, a TKLM server 700, akey store 702 having a database of keys, and a “KMIP” client 704. KMIPrefers to the Key Management Interoperability Protocol (KMIP), which isa new standard for key management sponsored by the Organization for theAdvancement of Structured Information Standards (OASIS). KMIP isdesigned as a comprehensive protocol for communication betweenenterprise key management servers and cryptographic clients (e.g., froma simple automated device to a sophisticated data storage system). Byconsolidating key management in a single key management system that isKMIP-compliant, an enterprise can reduce its operational andinfrastructure costs while ensuring appropriate operational controls andgovernance of security policy. KMIP treats cryptographic clientsuniformly and as entities that are intelligent and themselves capable ofspecifying cryptographic information, such as correct key sizes,encryption algorithms, and the like. Key lifecycle operations supportedby the protocol include generation, submission, retrieval and deletionof cryptographic keys.

Referring back to FIG. 7, the TKLM server 700 and associated key store702 provide an enterprise key management solution enables KMIPcommunication with KMIP clients (such as client 704) for key managementoperations on cryptographic material. The material includes, withoutlimitation, symmetric and asymmetric keys, certificates, and templatesused to create and control their use. In operation, the key managementserver 700 listens for connection requests from KMIP clients that sendrequests to locate, store, and manage cryptographic material on theserver. Using the server 700, the enterprise manages the lifecycle ofthe keys and certificates. Thus, for example, among other functions, theserver enables basic key serving, such as definition and serving ofkeys, definition of keys or groups of keys that can be associated with adevice (e.g., disk systems, drives, smart meters, mobile devices, etc.),and the like, as well as auditing functions. In a typical scenario, theserver supports KMIP secret data and symmetric key interoperabilityprofiles for KMIP server and client interactions. The server providesKMIP information, such as whether KMIP ports and timeout settings areconfigured, current KMIP certificate (indicating which certificate is inuse for secure server or server/client communication), whether SSL/KMIPor SSL is specified for secure communication, and so forth. The servermay also provide updating KMIP attributes for keys and certificates. Theserver 700 serves keys at the time of use to allow for centralizedstorage of key material in a secure location. It also includes agraphical user interface (or, in the alternative, a command line orother programmatic interface) by which administrators (or otherpermitted entities) centrally create, import, distribute, back up,archive and manage the lifecycle of keys and certificates. Using theinterface, administrators can group devices into separate domains,defines roles and permissions, and the like. By default, typically,groups of devices only have access to encryption keys defined withintheir group. These role-based access control features enable separationof duties, mapping of permissions for what actions against whichobjects, and enforcement of data isolation and security in amulti-tenancy environment. This also enhances security of sensitive keymanagement operations. All KMIP clients transacting business with TKLMserver 700 are subject to successful trust establishment with mutualauthentication before any key transactions begin with the TKLM server.

FIG. 8 illustrates how keys may be structured and organized by the keymanagement sub-system of the security management system. Internally, thekeys in the TKLM server 700 are stored in a protected data store 702.TKLM recognizes crypto keys using just a Device Storage identifier,which typically is a 12-24 digit alphanumeric serial number. Keys orcertificates are the entities served to clients. Symmetric keys eithercan be defined for one-to-one communications between just two entitiesor for a larger group by using a notion of device groups (whichrepresent a group of known storage identifiers) that can share a groupof keys. Each device group can have separate administrators withspecific privileges. In FIG. 8, the Storage ID 800 acts a unique keyidentifying handle. The crypto key set 802 comprises the symmetric keys(or wrapped symmetric keys) with the associated recipient public keycertificate. The device group 804 represents a collection of storageIDs, and their associated keys/certificates that belong to one group forcommon administration.

In operation, the TKLM server 700 assists encryption-enabled devices ingenerating, protecting, storing, and maintaining encryption keys thatare used to encrypt and decrypt information that is written to and readfrom devices. The key management server 700 acts as a background processwaiting for key generation or key retrieval requests sent to it througha TCP/IP communication path between itself and various devices, such assome other management system, a device driver, a disk controller, anetwork switch, a smart meter, and others. These are merelyrepresentative cryptographic client devices. When a client writesencrypted data, it first requests an encryption key from the keymanagement server. KMIP standardizes communication between cryptographicclients that need to consume keys and the key management systems thatcreate and manage those keys. It is a low-level protocol that is used torequest and deliver keys between any key manager and any cryptographicclient. KMIP uses the key lifecycle specified in NIST SP800-57 to defineattributes related to key states. Network security mechanisms, such asSSL/TLS and HTTPS, are used to establish authenticated communicationbetween the key management system and the cryptographic client.

Referring back to FIG. 7, as noted above the security managementsolution of this disclosure also leverages an asset managementsub-system. This portion of the solution may utilize the existing assetmanager 706 in the enterprise, or it may be a separate component (or acomponent integrated with the key management or event managementsub-systems, as described above). The asset management componentprovides the ability to create an authoritative source of record of allthe assets owned (or managed) by the grid utility. The asset managerpreferably includes or has associated therewith a work order component708 that is operative to identify tools and/or personnel for aparticular task, as well as estimates for time frames, financial costs,and the like. The work order component 708 includes a task dispatchercomponent that is controlled by an enterprise business process workflow.For example, and without limitation, the work order component mayrespond to a crew dispatch request that originates from an outagemanagement system 710. The work order component may also orchestrateautomated tasks associated with the data center.

As also seen in FIG. 7, the security management solution of thisdisclosure leverages the event management sub-system 712. Preferably,and as noted above, this sub-system is a real-time event dispositionsystem that has the ability to capture events from diverse sources, tocorrelate them with a rich abstraction of context around the event, andto take actionable step(s), such as incident management or troubleticket reporting. As noted above and as will be described in more detailbelow, the event management sub-system 712 typically inter-operates withthe other components of the solution when security events involvingpotential key compromises occur. As also noted, the event managementsub-system 712 is not required to play any active role with respect toother types of events, e.g., in the initial configuration of keys duringservice relationship establishment, as is now described by a second usecase.

In particular, and with continued reference to FIG. 7, another exampleuse case is now described. In this example scenario, a businessapplication (such as a billing application in the billing system 714)needs to establish connection with some operational equipment (such asthe smart meter) and then reads its data for billing settlement. As persecurity policies, it is assumed that certain elements of the data needsto be cryptographically signed (for establishing integrity), as well asencrypted (to protect user privacy concerns). This requires that keysbetween the billing application and the meter head-end, as well asbetween the head-end and the smart meter itself, have to be establishedand shared to ensure that data security is enforced end-to-end. It isassumed that the asset management system 706 maintains a repository ofall the IT and operational assets of the energy/utility company. Thisrepository is maintained in an XML manifestation of the CIM (CommonInformation Model)-UML model, with defined relationships andassociations between devices and applications. It is further assumedthat the grid applications interpreting XML data have knowledge of thesyntax and semantics to be used; typically, this is accomplished usingXML Schema, which provides constraints on the structure and contents ofthe XML document. Extensions to XML Schema are made to allow for deviceand application security characteristics to be introduced and embeddedwithin the semantics. One of these extensions (an extended attribute) isthe Storage ID of the cryptographic key(s) each node (i.e. meter device,head-end, application, or the like) is to be associated with.Preferably, the security attributes in the XML repository do notthemselves contain keys.

With the above assumptions, FIG. 7 illustrates one possible way ofmanaging this relationship. At step (1), the smart meter on initialdeployment registers through its head-end system, which publishes themeter registration event. This event (which is an example of an eventthat is not a security event identified by the event managementsub-system) triggers an enterprise service bus (ESB) mediation module716, which at step (2) registers the smart meter with the asset manager706. At step (3), the billing application in the billing system 714expresses its need to connect with the smart meter by sending a requestto the work order component 708. The work order component 708 recognizesthat the billing application cannot be connected directly to the smartmeter but must also connect through the head-end; the work ordercomponent initiates the right connectivity among the three components(billing application, head-end and smart meter) by sending a request tothe asset manager 706 for an appropriate configuration record. This isstep (4). Steps (3)-(4) may occur asynchronously with respect to steps(1)-(2). The asset manager 706 has an associated configuration database718 in which the configurations are stored. Within database 718,extensions to the IEC CIM schema allow the meter to be associated withthe head-end, and the billing application to be associated with thehead-end. Preferably, these associations are enabled bycross-referencing such relationship dependencies. In this manner, theasset manager component enables the necessary security associations tobe identified and linked as necessary.

As noted above, according to this disclosure, the work order (or someothers) component 708 has the KMIP client 704 associated therewith. Asnoted, the device-to-work order component communication paths aremutually authenticated, as is the communication path between the client704 and the TKLM server 700. Although not required, the work ordercomponent 708 and the TKLM server both may reside in the same trusted,restricted network that is secured with intrusion protection appliances.

Key establishment may then occur as follows. By convention, whenappropriate to signify both segments, the term “tuple” refers to both(e.g., segment A being the “application to head-end” association, andsegment B being the “head-end to the meter” association). In thisexample, the segment A path (application to head-end) cross-referencessegment A (the head-end to the meter). At step (6), the work ordercomponent 708 through its associated KMIP client 704 initiates a keyestablishment sequence. Similarly, the head-end to meter tuple followsin a like manner. In particular, the work order component 708 generatesa handle for the two segments to be used as a Storage ID; the component708 then submits this Storage ID to the TKLM server, requesting asymmetric key be generated against this handle. The KMIP protocolsecurely exchanges the key with the work order component, which entersthe handle and the respective key in the configuration database 718 withrespect to the billing application and the associated meter head-end. Asnoted above, preferably the actual key does not reside in theconfiguration database. In the preferred embodiment, the actual key isonly available in the TKLM server key database 702, which is secured bythe TKLM server 700. The TKLM server associates this key with the handleand returns the key to the KMIP client during the operation. At step(7), the key is returned, e.g., using Secure Web Services or othertransport, to the billing application, as well as to the meter head-end(or other ESB data security enforcement point) to enable data fields forthe meter and the billing application to be digitally-signed (for dataintegrity) and/or encrypted (for data privacy). The key returned mayalso be a key (a “wrapped key”) that is wrapped with a pre-sharedasymmetric key-encrypting key established by the TKLM server.

FIG. 9 illustrates how this security management system handles automatedkey revocation/refresh upon a security compromise. This is a morespecific example of the operations shown in the process flow of FIG. 6.In this example, a security event, such as equipment (meter) tamperingis detected. The event management sub-system 912 processes thisreal-time event. The event may also be identified by any meter vendorevent management functionality (if present). As seen in FIG. 9, at step(1) the meter security compromise incident is then submitted (as anaction item) to the work order management system 908. The action itemtypically includes details which meter(s) are affected. At step (2), thework order component 908 queries the asset management system 906 toretrieve the CIM information about each meter, thereby obtaining the keyhandle of the meter(s) affected. During this interaction, the assetmanagement system 906 may query its associated configuration database918 (step (3)). At step (4), and for each affected endpoint (e.g., themeter head-end, and the smart meter) and for each associated businessapplication (e.g., billing application 914), the work order managementcomponent 908 sends a key revocation command. The following describesthe key revocation and refresh for segment A (the “application tohead-end” association). In particular, after the command is acknowledgedas being successful, the work order management component 908 continuesat step (5) using the appropriate handles to cause its associated KMIPclient 904 to interact with the TKLM server 900 and thereby delete thekey entry from the TKLM database 902. At step (6), the work ordermanagement component 908 uses the handles and its KMIP client 904 torequest the TKLM server to generate a new key. At step (7), the new keyis securely refreshed in the business application (the billing system)and the affected endpoint (the head-end) to complete the key revocationand refresh process that was triggered initially by the monitoredsecurity event. Similar steps are used to refresh the segment B tuple(the “head-end to the meter” association).

As noted above, other types of events that have a bearing on securitymay also be managed by the techniques of this disclosure. Anotherexample scenario involves conditioned monitoring for periodic keyrefresh. In this example use case, a timed event within the work ordermanagement system occurs, say, event 90-120 days, e.g., to signify thatit is time for a routine maintenance task. In this example, the task isto change the cryptographic keys for one or more cyber-sensitive assets,just like one changes passwords to identity credentials every so often.This event typically is self-triggered, but it may also be identified insome other manner (even by the event management sub-system); inresponse, the work order management component queries the assetmanagement component (and its configuration database as described above)for all the impacted event-asset associations. The impacted keys arethen refreshed in the manner described above. A representative algorithmfor this operation is shown in FIG. 10. This algorithm typicallyexecutes in the work order component, using its associated KMIP client,as also described above. The routine begins at step 1000 to read allauthorized entries in the work order management configurationrepository. At step 1002, a test is performed to determine whether allentries have been processed; if so, the routine ends at step 1004. Ifthere is a next entry to process, the routine continues. At step 1006,and for the next entry, the routine causes the KMIP client to transactwith the TKLM server to generate a new key, which is then returned. Atstep 1008, the routine reads the Storage ID of the selected entity. Atstep 1010, the routine identifies all associated applications andendpoint entities using the same Storage ID. At step 1012, the routineprovides the new key for the associated entities. Control is thenreturned to step 1002.

The subject matter herein provides significant advantages. The approachprovides a unified solution for cryptographic key management acrossmultiple and disparate technologies, products and business systems thatcomprise the smart grid. Key management is enabled in a well-rounded,holistic manner to provide for coordinated communication and thus timelycorrective security measures to be enacted. The approach minimizes theimpact to sensitive data of a security compromise, thereby providingsignificant protection for critical cyber assets. The workload-basedapproach described automatically orchestrates key creation, keyrevocation and key refresh directives across associated components inthe IT and operational realms of the smart grid, even if the componentsare unrelated to one another, sourced from disparate vendors, or wouldnot otherwise inter-operate.

The approach ensures that cryptographic keys are always secure, whetherin transit or at rest. By associating the cryptographic key managementlifecycle with asset management, the approach ensures that the utilityfield equipment can enforce data security without the usual conundrum ofmanaging potentially thousands of keys for a large number of assets. Inthe event of keys being compromised, the security management solutionprovides pro-active action to revoke and refresh the keys. The approachalso enables revocation/refreshing to be part of a regular maintenancecycle. The techniques here also enable condition-based monitoring ofcryptographic keys for a cyber-asset connected to some operational gear.The approach also enables keys to be dynamically refreshed only asneeded, e.g., for only those portions of the asset/configurationdatabase that are impacted by a security event, a routine maintenancerequirement, or the like.

In a preferred embodiment, the cryptographic keys are symmetric keys,although this is not a requirement, as the key management techniques maybe applied for any cryptographic materials or operations.

As has been described, the functionality described above may beimplemented as a standalone approach, e.g., a software-based functionexecuted by a processor, or it may be available as a managed service(including as a web service via a SOAP/XML interface). The particularhardware and software implementation details described herein are merelyfor illustrative purposes are not meant to limit the scope of thedescribed subject matter.

More generally, computing devices within the context of the disclosedsubject matter are each a data processing system (such as shown in FIG.2) comprising hardware and software, and these entities communicate withone another over a network, such as the Internet, an intranet, anextranet, a private network, or any other communications medium or link.The applications on the data processing system provide native supportfor Web and other known services and protocols.

Still more generally, the subject matter described herein can take theform of an entirely hardware embodiment, an entirely software embodimentor an embodiment containing both hardware and software elements. In apreferred embodiment, the security management solution (or any componentthereof) is implemented in software, which includes but is not limitedto firmware, resident software, microcode, and the like. Furthermore,the described functions can take the form of a computer program productaccessible from a computer-usable or computer-readable non-transitorymedium providing program code for use by or in connection with acomputer or any instruction execution system. For the purposes of thisdescription, a computer-usable or computer readable medium can be anyapparatus that can contain or store the program for use by or inconnection with the instruction execution system, apparatus, or device.The medium can be an electronic, magnetic, optical, electromagnetic,infrared, or a semiconductor system (or apparatus or device). Examplesof a computer-readable medium include a semiconductor or solid statememory, magnetic tape, a removable computer diskette, a random accessmemory (RAM), a read-only memory (ROM), a rigid magnetic disk and anoptical disk. Current examples of optical disks include compactdisk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) andDVD. Storage devices may include removable media, such as SD cards. Thecomputer-readable medium is a tangible, non-transitory item. Any ofthese devices can be used to store information protected by the system.

Any cloud datacenter resource may host a security management solutioncomponent as described herein.

The computer program product may be a product having programinstructions (or program code) to implement one or more of the describedfunctions. Those instructions or code may be stored in a computerreadable storage medium in a data processing system after beingdownloaded over a network from a remote data processing system. Or,those instructions or code may be stored in a computer readable storagemedium in a server data processing system and adapted to be downloadedover a network to a remote data processing system for use in a computerreadable storage medium within the remote system.

In a representative embodiment, the security management solutioncomponents are implemented in a special purpose computing platform,preferably in software executed by one or more processors. The softwareis maintained in one or more data stores or memories associated with theone or more processors, and the software may be implemented as one ormore computer programs. Collectively, this special-purpose hardware andsoftware comprises the functionality described above.

Further, the functionality provided herein may be implemented as anadjunct or extension to an existing cloud compute management solution.

The techniques described herein may be used in virtual client-serverenvironments.

The techniques herein may be used in other than the energy and utility(smart grid) industries, as they may be applied to other fields such aslogistics, natural resource monitoring/management, smart city,telecommunications and health care, in the chemical and petroleumindustries, and many more, wherein cryptographic keys need to be managedacross networks, communications and computing technologies.

While the above describes a particular order of operations performed bycertain embodiments of the invention, it should be understood that suchorder is exemplary, as alternative embodiments may perform theoperations in a different order, combine certain operations, overlapcertain operations, or the like. References in the specification to agiven embodiment indicate that the embodiment described may include aparticular feature, structure, or characteristic, but every embodimentmay not necessarily include the particular feature, structure, orcharacteristic.

Finally, while given components of the system have been describedseparately, one of ordinary skill will appreciate that some of thefunctions may be combined or shared in given instructions, programsequences, code portions, and the like.

Having described our invention, what we now claim is as follows:
 1. Amethod of key management in a delivery network comprising a plurality ofnodes, each node supporting an entity, comprising: responsive tooccurrence of an event, generating a set of event-asset associations byidentifying one or more configuration records, and identifying one ormore assets defined in the identified configuration records that mayhave generated the event, wherein the one or more assets are identifiedby examining a configuration of assets in an asset database associatedwith the delivery network to identify each event-asset association;using the set of event-asset associations so generated,cross-referencing a first event-asset association that is associatedwith a first application software system, with a second event-assetassociation that is associated with a second application softwaresystem, the second application software system being distinct from thefirst application software system, to thereby generate cross-referencedevent-asset associations for the first and second application softwaresystems; based at least on the cross-referenced event-assetassociations, deriving a key handle; using the key handle to initiate akey management operation; and performing the key management operationfor each of the first and second application software systems as aresponse to the event; wherein the delivery network is a smart grid, andthe nodes are one of: a meter device, and a business application.
 2. Themethod as described in claim 1 wherein the first and second applicationsoftware systems are managed by distinct business entities.
 3. Themethod as described in claim 1 wherein the key management operation isone of: generation, establishment, retrieval, revocation and refresh. 4.The method as described in claim 1 wherein the event is one of: an eventtriggered upon compromise of an entity, an event triggered uponestablishment of a service connection from an entity, and a timed eventassociated with a task associated with an entity.
 5. The method asdescribed in claim 1 wherein the key management operation uses asymmetric key and is initiated using a Key Management InteroperabilityProtocol (KMIP).
 6. Apparatus, comprising: a processor; computer memoryholding computer program instructions that when executed by theprocessor perform a method of key management in a delivery networkcomprising a plurality of nodes, each node supporting an entity, themethod comprising: responsive to occurrence of an event, generating aset of event-asset associations by identifying one or more configurationrecords, and identifying one or more assets defined in the identifiedconfiguration records that may have generated the event, wherein the oneor more assets are identified by examining a configuration of assets inan asset database associated with the delivery network to identify eachevent-asset association; using the set of event-asset associations sogenerated, cross-referencing a first event-asset association that isassociated with a first application software system, with a secondevent-asset association that is associated with a second applicationsoftware system, the second application software system being distinctfrom the first application software system, to thereby generatecross-referenced event-asset associations for the first and secondapplication software systems; based at least on the cross-referencedevent-asset associations, deriving a key handle; using the key handle toinitiate a key management operation; and performing the key managementoperation for each of the first and second application software systemsas a response to the event; wherein the delivery network is a smartgrid, and the nodes are one of: a meter device, and a businessapplication.
 7. The apparatus as described in claim 6 wherein the firstand second application software systems are managed by distinct businessentities.
 8. The apparatus as described in claim 6 wherein the keymanagement operation is one of: generation, establishment, retrieval,revocation and refresh.
 9. The apparatus as described in claim 6 whereinthe event is one of: an event triggered upon compromise of an entity, anevent triggered upon establishment of a service connection from anentity, and a timed event associated with a task associated with anentity.
 10. The apparatus as described in claim 6 wherein the keymanagement operation uses a symmetric key and is initiated using a KeyManagement Interoperability Protocol (KMIP).
 11. A computer programproduct in a non-transitory computer readable medium for use in a dataprocessing system, the computer program product holding computer programinstructions which, when executed by the data processing system, performa method of key management in a delivery network comprising a pluralityof nodes, each node supporting an entity, the method comprising:responsive to occurrence of an event, generating a set of event-assetassociations by identifying one or more configuration records, andidentifying one or more assets defined in the identified configurationrecords that may have generated the event, wherein the one or moreassets are identified by examining a configuration of assets in an assetdatabase associated with the delivery network to identify eachevent-asset associations; using the set of event-asset associations sogenerated, cross-referencing a first event-asset association that isassociated with a first application software system, with a secondevent-asset association that is associated with a second applicationsoftware system, the second application software system being distinctfrom the first application software system, to thereby generatecross-referenced event-asset associations for the first and secondapplication software systems; based at least on the cross-referencedevent-asset associations, deriving a key handle; using the key handle toinitiate a key management operation; and performing the key managementoperation for each of the first and second application software systemsas a response to the event; wherein the delivery network is a smartgrid, and the nodes are one of: a meter device, and a businessapplication.
 12. The computer program product as described in claim 11wherein the first and second application software systems are managed bydistinct business entities.
 13. The computer program product asdescribed in claim 11 wherein the key management operation is one of:generation, establishment, retrieval, revocation and refresh.
 14. Thecomputer program product as described in claim 11 wherein the event isone of: an event triggered upon compromise of an entity, an eventtriggered upon establishment of a service connection from an entity, anda timed event associated with a task associated with an entity.